GitHub Enterprise CloudでSAML SSOするときのIdPに「Auth0」を使う場合の手順

GitHub Enterprise CloudでSAML SSOするときのIdPに「Auth0」を使う場合の手順

Clock Icon2024.02.22

今回検証するシナリオは以下のとおりです。

「GitHub Enterprise Cloud (GHEC) では、SAML SSOを使用して、異なるユーザーグループ(社員と外部パートナー)に対して異なる認証プロセスを提供する」

■外部パートナーの認証プロセス:

  • 外部パートナーがGHEC内の組織管理下のプライベートリポジトリにアクセスしようとする
  • GitHubにログインしていない場合、ユーザーはGitHubの標準ログインページにリダイレクトされる
  • SAML SSOが設定されている場合、GitHubのログインページから外部パートナーはAuth0にリダイレクトされる
  • パートナーはAuth0でSAML認証を行い、成功するとSAMLアサーション(認証情報)を受け取る
  • パートナーはこのSAMLアサーションをGHECに提供し、アクセスが許可される

■社員(プロパー)の認証プロセス:

  • 社員(プロパー)は、GHECのIdPであるAuth0を介してログインするが、そのプロセスではさらに別のAuth0アプリケーションにSAMLフェデレーションする
  • この別のAuth0アプリケーションは、社員専用の認証基盤として機能し、社員の認証を行う
  • 社員はこの認証基盤でSAML認証を成功させると、GHECにアクセスするためのSAMLアサーション(認証情報)を受け取る
  • 受け取ったSAMLアサーションをもって、社員はGHECのプライベートリポジトリへのアクセスが許可される

このようなフローとなります。

社員(プロパー)の認証プロセスについては、IdP②でSAMLフェデレーションしていますが、ここはMS EntraIDなど、さまざまな接続に置き換えることが出来ます。

やってみた

早ければ、15分ほどで設定が終わり動作確認できると思います。

1. 外部パートナーの認証プロセス:GHECとIdP(Auth0)のSAMLフェデレーション

詳しい手順は Auth0 Docs「Configure GitHub Enterprise Cloud as SAML Service Provider」を確認してください。

■Auth0側の設定

  • アプリケーションを作成します。

  • アプリケーションのSAML2 WEB APPを有効化します。

■GHEC側の設定

  • OrganizationにSAML SSOの設定を行います。

■動作確認

  • まず、個人のGithubアカウントでログインします。
    • Githubは規約により複数の無料アカウント持つことは出来ません。
  • その後、プライベートリポジトリにアクセスするとSSOの処理がはじまります。ボタンを押下するとAuth0アプリケーションのログイン画面にリダイレクトします。

  • Auth0側で認証が成功すると、プライベートリポジトリが表示されます。

2. 社員(プロパー)の認証プロセス:IdP①(Auth0)とIdP②(Auth0)のSAMLフェデレーション

こちらの記事を参考にしました。

Auth0からAuth0へのSAMLフェデレーションするケースは、少々特殊な気がします。

■IdP②の設定

  • 先ほど設定していたテナントとは別のテナントを作成します。
  • その後、アプリケーションを作成します。

  • このアプリケーションはIdPなのでSAML設定値をメモします。

  • Certificateもメモします。

  • アプリケーションのSAML2 WEB APPを有効化します。

■IdP①の設定

  • SAML接続を作成します。

  • 今回は、SAML認証ボタンを表示します。

■動作確認

  • さきほどと同じ手順でSSOの処理を開始し、ログイン画面を表示します。

  • IdP②のユーザーでログインすれば、プライベートリポジトリが表示されます。

感想

  • 後から気づいたのですが、Auth0 Marketplaceに統合ツールが用意されていました。こちらを使って設定する方がIdP/SPのアプリケーションを作成しない分、簡単でした。

  • 今回のケースだと、GithubアカウントとAuth0と両方でログイン操作をするのは正直面倒に感じました。GHECには、EMU(Enterprise Managed User)と言って、運用管理側でアカウントを一元的に発行して認証させる仕組みがあるようです。
  • 監査ログ・SSO強制・MFA・組織横断の認証・権限制御・アクセス制限など、まだまだ考慮すべきことはありそうです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.